Argh these IFX CI errors seem to be intermittent. Sometimes they crop up and sometimes they don't.

@copilot Diagnose the (potentially intermittent) errors in the Fortran CI under the IFX compiler.

@copilot Diagnose the (potentially intermittent) errors in the Fortran CI under the IFX compiler.

Here's the diagnosis and fix.

Consistent failure — IFX 2023.1.0 + LLVM 16 (all 6 tests, every run)

The Fortran test pipeline chains two opt calls:

1. opt %loadEnzyme %enzyme — applies Enzyme; for LLVM 16, %loadEnzyme already passes -opaque-pointers=0, so the output bitcode uses typed pointers.
2. opt -ON -S — optimises and writes text IR — without -opaque-pointers=0.

LLVM 16 defaults to opaque pointer mode, so step 2 converts the typed-pointer bitcode to ptr-typed IR. IFX 2023.1.0 is built against an older LLVM that cannot parse ptr types, so it crashes with error #5623: Internal compiler error: internal abort.

Fix (commit Fix IFX 2023.1.0 + LLVM 16): Added a %optflags substitution to lit.site.cfg.py.in that expands to -opaque-pointers=0 for LLVM 16 and is empty for all other versions. Applied it to the second opt call in all 6 failing Fortran tests so the text IR output stays in typed-pointer form that IFX 2023.1.0 can consume.

Intermittent failure — IFX 2023.2.4 + LLVM 17 (Release only, very rare)

Seen once in an earlier run: Enzyme: failed to find fn to differentiate call void (...) @selectfirst__enzyme_fwddiff_. When IFX 2023.2.4 compiles at -O1/higher with LTO and the function body is not co-located, it can emit the call with a varargs (...) signature. Enzyme then cannot locate the underlying function to differentiate. This is non-deterministic (depends on what IFX's LTO pass scheduler does at that run), passes in the vast majority of runs, and is a separate, pre-existing issue unrelated to the opaque-pointer bug. It would need a deeper investigation into how IFX generates LTO IR for Fortran explicit interfaces.